Size Change: +74 B (0%)

Total Size: 1.51 MB

_{compressed-size-action}

The problem here is now that if you enter custom label text for your link it will be overwritten again by the data returned from the API.

We need to

• respect the label if the user has provided it directly
• still update the label if it is the default one originally set on the link and needs to be updated to match the changes to the referenced post entity

To do this we probably never actually want to set either label or url as an attribute for the block when initially creating the Link using the Link Control. Rather we should always retrieve these dynamically from the post entity.

Then if there is an existing label attribute we can assume this has been set manually by the user and thus should be considered canonical and should not be overwritten with updates from the entity.

We should probably also disallowed custom editing of the Link if the link is dynamically generated from the ID. Rather we should simply force LinkControl to show the value of the link but not allow you to edit it.

This would be consistent because it will be very confusing to be able to edit a link which references an entity whilst also having that link dynamically kept in sync with the underlying entity.

We will also have to make the same dynamic look up for other types of referenced entities such as terms and media (basically anything supported by LinkControl).

The experience I get with this is that when I edit the link name and then save, the nav is refreshed and my changes are lost:

The way I would expect this to work is that the editing experience would be the same as the creation experience.

When I create a new link I see this:

But then when I edit I am given an interface like this:

While it is useful to be able to edit these details, I think it should be a secondary action - the primary action should be to return me to the same view as when I created the link, with a search box and a list of pages to select from...

Here's an idea to get the ball rolling:

Pinging @jasmussen @jameskoster and @SaxonF for some input!

Just a note to say I think the design problem that needs consideration is how the Link Control interface can display the state of a selected "entity". For example, if you search and then select a Page from the list of results then how does the edit interface look for that? Should it differ from the example where you have manually entered a URL (e.g. www.google.com)?

The objective is that if a link is to an internal WP entity (e.g. a Post) then that URL of that link should be dynamically retrieved and displayed. Currently the code and UX of the Link UI relies on a URL and will fail if one isn't provided. Therefore whilst we look up the URL the Link Control interface looks broken.

We need a means of communicating "this link is to an entity" vs "this link is a manually entered URL".

I advise testing this PR as it will showcase some of the issues which can be difficult to describe in text form.

For example, if you search and then select a Page from the list of results then how does the edit interface look for that? Should it differ from the example where you have manually entered a URL (e.g. www.google.com)?

My instinct is yes, they should be different. Internal content should probably have a more token-like apperance and not be editable at all (except to swap entries). Whereas a custom link should just be inputs. At the moment both are mixed which I agree feels a bit flaky.

It seems like the issue at hand would be improved by this design:

That is, each item is more of a "token" you link to, rather than just a loose association between title and URL. I think I shared this design also on a link dialog issue, but I forgot which one. In case one of you remember, I'd appreciate it 🙏

That is, each item is more of a "token" you link to, rather than just a loose association between title and URL.

I agree with this 👍

The designs are a good step. They focus on the link creation UI.

However, from an implementation perspective what I'd really find useful to see are the states for when

• a "token" has been selected.
• a "token" is being edited (having already created it)

🙇

However, from an implementation perspective what I'd really find useful to see are the states for when

I can look at this. @jasmussen any chance you can find the Figma for the above?

Quick pass at the edit link UI. This just adjusts so url field value acts more like a token rather than input, and after clicking edit we use the existing UI for entering page/url value. OnBlur reverts back to current page.

I can look at this. @jasmussen any chance you can find the Figma for the above?

Yes, this is the Figma file I worked in, but feel free to extract it somewhere more ergonomic.

Your quick pass looks good!

It reminds me we could benefit from a new edit icon that works a bit better in these utilitarian contexts. I made this one for a separate conversation, but I'm not sure it still threads the needle:

Something to look at separately.

Do we need to show the URL in the "resting" state? If there's an affordance to edit it, perhaps just Page icon plus "Home" label would make it feel more like a token as discussed? Can always show the URL as a tooltip if need be.

We probably shouldn't change the popover appearance (border, shadow, radius) as part of this effort, can discuss that separately if need be. Nice work!

Here's an updated concept considering some of the other items listed in #35073:

• I’ve removed the “Create new page” flow because I think that’s better served elsewhere, but it’s easy to add back if there are strong feelings.
• Apply / Cancel buttons provide better understanding of how to confirm or discard changes, and address some a11y issues.
• Settings section provides a home for the options we want to add, and for third parties to extend.
• Added a "Target" dropdown rather than having separate switches for "Open in a new tab" and "Nofollow", but separate switches could work as an interim.

How do we feel about this? Does the cog work for the settings toggle button, or should we use the Settings icon? In terms of size, I used 36px to match the Apply/Cancel buttons, but I think there's a movement towards 32px or 40px for these controls... what do you think @jasmussen?

I now centralised all design discussion in #47310

Coming back to this. Here are the requirements to allow for these dynamic updates.

The UI needs to reflect the fact that if you select a link to a Post entity (e.g. Page, Post...etc) you have linked to something which is a reference to that post. Therefore in this state, this means the URL field should become read-only and no editing should be allowed. Moreover, the UI should communicate that you have linked to a Post object and not just a manually entered URL (such as www.google.com).

This UX would mean that if the URL of the referenced post changes then it's simple for us to dynamically update the URL that's shown in the interface.

Now if the user opts to edit the URL field then that could be allowed but it would cause the link to the Post to be severed and from that point it would be a non-dynamic link.

Flaky tests detected in 9128d72.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5977073360
📝 Reported issues:

• [Flaky Test] should partially select with shift + click (@webkit) #53524 in /test/e2e/specs/editor/various/multi-block-selection.spec.js

@SaxonF Are you still happy with the design route from #46891 (comment)?

cc @richtabor

Would it be possible to add an anchor to a link while keeping it dynamic?

@getdave Im not completely up to date with the Link UI but #49091 (comment) is the more recent interpretation of that concept. ie input becomes a dynamic token where appropriate.

@richtabor is probably the better person to make a decision on whether that approach still makes sense or not. (sorry Rich :D )

Would it be possible to add an anchor to a link while keeping it dynamic?

This is a very good point and one which would require careful consideration. Thank you.

The UX infrastructure we put in place in this PR will also allow this to be rolled out to the rich text implementation of links.

The current solution is mainly focused on the core/navigation block.

Therefore I am wondering about two things:

• Will this approach also fix the same problems in other places that use the LinkControl element? Like post content and core/button?
• Will the solution be "backwards compatible" for links that are already added to the content?
  • Will the available data be sufficient to find the correct post?
  • Do we even want the already added links to be backwards compatible (I'd think so but maybe there are arguments against this)

Next steps here are to continue to enhance the Link UI with support for links which represent an entity. In such circumstances the URL field should be disabled.

The main blocker is how to allow authors to add a internal anchor link to a link of this type without severing the connection to the entity.

We also need to consider how this might apply to other scenarios outside of Navigation such as inline links in Rich Text which also save an id attribute representing the underlying post object.

Noting that an alternative approach might be to take advantage of the proposed attribute sources in the Blocks API to connect the various block attributes with the equivalent Post fields

#54536